Edit this article

Last edited 17 Nov 2022

Main author

CIOB Institute / association Website

Risk management

[edit] Introduction

A risk is a potential event, either internal or external to a project, that, if it occurs, may cause the project to fail to meet one or more of its objectives.

A project by definition is trying to introduce some form of change; a new building, production system or way of working. Change involves uncertainty, which in turn means that projects are more likely to be blown off course by a potential future event. In other words, projects are inherently risky undertakings.

Project managers need to recognise that risks exist and actively manage them; this is an indication of good project management, not an admission of failure. By looking ahead at potential events that may impact on the project and by putting actions in place to address them, project teams can pro-actively manage risks and increase the chances of successfully delivering the project.

Risk has two aspects:

The expected likelihood (or probability) of an event occurring.
The expected impact if it does occur.

An ‘issue’ in project management terms is something that is happening now and is jeopardising (or will soon jeopardise) the delivery of one or more of a project’s objectives or deliverables. It may therefore represent a risk that has materialised (in other words one where the probability has reached 100%). A risk may turn into an issue (when the risk occurs); an issue will not turn into a risk, because by definition, it has already occurred.

Risk management aims to recognise potential problems as early as possible so that the opportunity for taking effective action is maximised.

[edit] Taxonomy of risks

Risks can be classified in relation to their locus of action, that is, the organisational level at which the risk will have the most impact.

[edit] Project risks

Those risks within the project boundary that could affect the delivery of the business outcome that the project is set up to deliver.

[edit] Business risks

Those risks that affect the operation of the business outcome once it has been delivered by the project.

[edit] Environmental risks

Those risks that are external to the project environment but which nevertheless can affect the project objectives.

[edit] External change risks

Those risks that are beyond the immediate project environment but which could have a major impact. Frequently in contractual terms these may include 'force majeure' events (exceptional, unforeseen events or circumstances that are beyond the reasonable control of the parties to a contract). However, external change risks go beyond force majeure, for example because of a shift in government policy or in its interpretation of a law.

See Risk for more information.

[edit] Risk management

The main aims of risk management are to:

Identify potential risks.
Assess the probability and impact of each risk.
Identify alternative actions that may prevent the risk from happening (avoidance), or if it does happen ameliorate the impact (reduction), or provide a strategy for dealing with the accepted consequences (acceptance).
Implement and monitor those actions that are cost effective and necessary to the successful delivery of the project objectives.
Provide feedback from experiential learning to improve the risk management of future projects and to inform the training and development of project managers.

Effective risk management should:

Anticipate and influence events before they happen by taking a proactive approach.
Provide knowledge and information about predicted events.
Inform and where possible improve the quality of decision making, recognising the hierarchy of risk avoidance, risk reduction, risk control, and risk acceptance.
Avoid covert assumptions and false definition of risks.
Make the project management process overt and transparent.
Assist in the delivery of project objectives in terms of benchmarked quality, time and cost thresholds.
Allow the development of scenario planning in the event of the identification of a high impact risk.
Provide improved contingency planning.
Provide verifiable records of risk planning and risk control.

[edit] Risk management plan

To achieve effective and efficient risk management, risk planning is required. The commonest form of risk planning is the Risk Management Plan (RMP).

A risk management plan (RMP) comprises:

The risk strategy, which records how risks will be owned, evaluated, controlled, reviewed and reported upon; the plan will show:

Who is accountable for a particular risk (ownership).
What that particular risk is (evaluation).
How that particular risk will be managed, controlled, reviewed and reported, in other words the physical actions or management actions that will be taken to avoid, reduce, control or accept the risk.

The key to effective risk management is ownership. Each risk (and associated actions) must be owned so that there is clear responsibility and accountability for that risk and its associated action. It has become an axiom of good risk management that the ownership of a risk should lie with the party ‘best’ able to control the risk probability and its impact.

Different risks and actions will need to be owned by different stakeholders. For example:

The client should own any risks that affect the business or business case (those risks that would prevent the benefits of the project from being fully realised).
The project manager should own any risks that might affect the delivery of the project (those risks that affect the project schedule).
The contractor should own any risks that might affect the contractors’ ability to deliver the project objectives.

The project manager may initially determine ownership, when risks are accepted and entered onto a risk log. It may then be ratified / agreed by the client or contractor.

The risk owner is responsible for ensuring that the risk is effectively monitored and managed through appropriate, agreed mitigating actions. The project manager has overall responsibility for the control of risks (and any actions associated with them) and the communication of the plan so that all parties understand their role(s). This includes reporting the presence of any risks that, if realised, would:

Affect the project base-line (the business case or schedule).
Affect the 'fit' of the project within the business strategy.
Affect dependent projects (or programmes). If the project is a part of a programme, such programme level risks will be managed by the programme management function.

[edit] The process

Risk management is about trying to eliminate the unexpected, by thinking about all the things that might happen to deflect a project from its objectives. The process can be divided in to 2 phases comprising 4 iterative stages, shown schematically below:

Each stage has a number of steps.

It is important to begin developing the RMP from as early on in the project as possible, when the feasibility appraisal or any full study is undertaken, or as a part of any financial appraisal, before formal project approval is sought. However, risk management is an ongoing part of project management. This is not just in terms of mitigation and control. It also means that the whole process should be repeated and re-assessed throughout the project.

Some key stages which might be suitable as review points are:

Between inception and initiating a project.
When managing phase boundaries, as one stage is completed and the next is planned in detail, as part of the management review.
As a part of full project reviews or internal reviews.

[edit] Risk identification

[edit] Identification

Identification is a key stage of the risk management process providing the foundation upon which the remainder of the process is built.

Key deliverables include:

The risk management strategy (recorded in the RMP).
A risk register for the project.

[edit] Context and perspective for analysis

Before identification can begin, the project must have clear scope, objectives and business strategy. It is important to outline the risk strategy at this stage. This will depend on the type of project and its complexity (in terms of number of stakeholders, dependencies and products, its length, timescales, budget, and so on).

It should set out:

The level of risk management required for the project. Will any risks be quantified or modelled (for example to test cost sensitivities or different likelihood of occurrence)? Or will qualitative analysis provide enough control?
What the levels or types of risk are for this project.
The process and frequency with which risks and actions will be reviewed. For example, will a special meeting of the project management team be needed?
The process for escalating risks. For example, if the project is a part of a larger programme.
The likely points within the project when the whole risk identification process will be repeated. For example, at the start of each new stage or phase when detailed plans are being developed.

[edit] Gather information on risks

There are a number of different techniques for identifying risks. Two of the commonest techniques are:

Brainstorming with key stakeholders to capture as many of the risks associated with the project as possible. It may also be worth involving those who have been undertaken other similar projects, so that their experience can be incorporated. As with all brainstorming the key thing at this point is to capture everything. Consideration of which risks to accept or to manage, comes later.
Checklists. These can seldom be exhaustive, but can help to ensure that the most common key areas of project risk are considered. They are particularly useful as 'prompts' to facilitate brainstorming.

[edit] Classify risks according to causes

Depending upon the size and type of project, it may be helpful to classify the risks. There are a number of ways of doing this, for example grouped according to causes (relating to customers, staff impacts, technology, and so on), project objectives or critical success factors (CSF’s), project activities or products.

[edit] Assessment

Once risks have been identified they need to be assessed so that decisions can be made about:

Which are the highest priority and therefore what level of management ownership they require.
The possible management actions that could be taken.

[edit] Determine the likelihood and consequences

All risks have two elements:

The likelihood that they will happen.
The impact on the project if they do happen.

Both of these elements need to be assessed so that risks and actions can be prioritised relative to one another. There are two main methods of doing this: qualitative and quantitative. All risks should be assessed qualitatively first, to give a feel for the relative riskiness of the project and the highest risks. Qualitative assessment looks at the relative likelihood and impact of any risk.

A first step could use the following:

Likelihood	High	Medium	Low
	It is very likely that this risk will happen	It is quite likely that this risk will happen	It is unlikely that this risk will happen

Different risks are likely to impact different aspects of the project. It is worth considering which type of impact is likely to be most critical to the project at the stage it has reached. The impact can then be focused upon this area - for example, costs could be considered as stage costs, development costs or whole project lifecycle costs.

Table: Examples of impacts on project taking into account their level

Impact Level

High

Medium

Low

Cost

Cannot be contained in project base-line

Unlikely to be contained in project base-line

Likely to be contained in project base- line.

Schedule (e.g. key milestones)

Project will not be delivered on time

Project unlikely to be delivered on time

Some slippage to milestone Schedule but not overall project schedule

Benefits

Business case deliverables are not achievable

Business case deliverables likely to be reduced

No real impact

The impact allocation is then taken to be the highest category for that risk in the three impacted areas.

NB: Impact on quality is likely to be reflected in some or all of the above, as, for example benefits include 'soft' issues such as customer service.

[edit] Initial ranking of order of importance

This will be a combination of the likelihood and the impact on cost, quality, schedule and benefits. A ranking technique can be used where: high = 3; medium = 2; low = 1. For each risk multiply the impact and likelihood together: the risks can then be ordered according to the highest score. In this system the highest risk ratio is 9 (high probability and high impact) and the lowest risk ratio is 1 (low probability and low impact).

Finally in this step, consider the timing of the highest scoring risks:

When are they likely to impact the project?
What does this mean for the possible management actions that could be taken?

Depending on the complexity of the project, it may be worth considering an additional dimension for describing the risk - its ‘urgency’ based upon how soon it will impact the project.

[edit] Mitigation

Once the identified risks have been prioritised and their timing has been established, possible management actions should be considered. These management actions are designed to contain the risk, by either making them less likely or by reducing their impact.

[edit] Decide on any actions

Using the ordered set of risks, decide whether any action should be taken and if so, what:

Prevent: An action which reduces the likelihood.
Mitigate: An action which reduces the impact to the project should the risk occur.
Transfer: Transfer the risk to someone who can better manage it, for example to the contractor (this is normally combined with acceptance) or partner the risk.
Contingency: A contingency plan which can be brought in to play should the risk occur, e.g. to deliver the business outcome (or part of it) in a different way.
Accept: No action will be taken - the risk is accepted as it is. For example, if the impact is very low, or the potential returns/benefits are very high.
Insure: Purchase an underwritten insurance policy that provides for financial restitution if the risk occurs.
Decline: Reject the risk – this may entail declining the entire project or entering into detailed negotiations with the prospective client.

Two additional categories of action are also worth considering:

Lack of root definition: Not enough information to make a decision - carry out further investigation.
Avoidance: A different course is taken so that the likelihood of the risk is reduced to zero. In other words the risk is avoided.

Actions aimed at reducing the probability __________________ Actions aimed at reducing the impact

Image: Risk management decision scheme.

Any management action must be assessed in terms of:

Cost.
The kind of action it is; this will affect when that action should be included within the project plan. For example, an action aimed at reducing the likelihood of a risk should be included in the project plan. An action affecting the impact will be contingent upon the occurrence of the risk and should therefore only be included in the plan if the risk occurs.
Its predicted effectiveness in containing the risk.
Its associated consequences - to ensure that the counter-measure does not have any unforeseen consequences. There is an assumption here that root definition has been achieved and that the action is not to relieve ‘mere’ symptoms.

These can then be compared to the risk assessment, to decide which actions are appropriate given the level of risk. Once a risk has been both accepted and appropriate countermeasures identified the risk and countermeasure owners should be agreed.

[edit] Risk metrics and milestones

For each risk that has an action, consider what measures or milestones will give early warnings that the risk is about to happen. These can then be monitored as a part of the risk management plan.

[edit] Create and agree a risk management plan

Create an initial management plan. The risk register can form the basis for this.

The nature of the plan will be dependent upon the type of risk, its timing and the type of counter-measure selected. For example, where a risk has been identified that is likely to occur in the current stage of the project and a preventative counter-measure is available, that counter-measure can be built into the activities within the project or stage plan. The action should still be controlled and managed through the RMP.

In contrast, contingency management actions are dependent upon the risk occurring and so will not be immediately built into the project plan. These measures have been “planned”, in that they have been considered and accepted, but are only put into operation within the project / phase plan as and when the risk arises and the action is authorised. Such management actions are therefore available as required.

The RMP (along with the other project plans) should be agreed, ensuring that all stakeholders are aware of any actions that are their responsibility.

[edit] Allocate resources and implement plan

Resource allocations should be pre-planned and, where appropriate, allocated to the agreed actions. Immediate actions should be built in with the other project activities as an integral part of the overall project management plan. Other actions will be dependent upon the risk materialising and will be triggered by risk metrics and milestones.

[edit] Control

The final stage is to:

Monitor risk metrics and milestones so that contingent actions can be implemented if required.
Monitor the effectiveness of risk management actions to ensure they are having the predicted effect. (Improper root definition may create unexpected events at other points within the system).
Feedback lessons about which actions are the most effective.

[edit] Monitor progress

Ensuring progress against the risk management plan involves:

Co-ordinating the risk activities alongside other project work (effective communication between the risk owner and the project manager is a necessity).
Monitoring resource usage against limits and resolving conflicts.
Monitoring risks to ensure that they remain within agreed limits.
Monitoring risks to ensure that they do not become too large for the project manager to manage effectively.
Monitoring risks to ensure that they do not threaten the viability of the project objectives.
Reporting risk as outlined in the risk strategy.
Re-evaluating the risks to the project as outlined in the risk strategy.
Invoke procedures for any risks or issues that fall outside the authority of the project team. For example, an environmental risk which impacts more than one stakeholder.
Invoke procedures for any risks or issues that are not being effectively managed by the risk owner, and as a consequence, other stakeholders may be adversely affected.

[edit] Cybernetic feedback

Cybernetic feedback is knowledge and experiential learning about the effectiveness of actions. For example, a preventative action may have been put in place to reduce the likelihood of a risk from high to medium.

Was this effective?
Did the risk materialise?
If so was this because the action was ineffective or for some other reason?
In retrospect might a different action have been more effective?

These lessons can be used to:

Improve ongoing risk planning on the project itself.
Share good practice with other projects.
Monitor risk metrics and milestones to assess which risks are happening or about to happen.

This will therefore involve both:

Checking whether risk metrics or milestones have been reached and therefore whether any contingent management actions are required.
Ensuring that indicators continue to give a clear picture of the status of that risk.

Where appropriate, reduction and contingency actions should be scheduled into the project plan.

[edit] Report progress

Monitor and report on the change of status of any risk. The precise method and frequency of reporting depends on the risk strategy for the project that was developed during inception. The project manager is responsible for reporting progress to the project team. Risk owners are responsible for monitoring and reporting on 'their' risks to the project manager.

In addition, they are responsible for reporting to the project manager, who is responsible for reporting to the project team the occurrence of any risks that:

Affect the project base-line, in terms of time, cost or quality of delivery of project objectives.
Might affect the congruence of the project with the business strategy.
Affect risk owners ability to manage other risks.
Affect dependent phases or work packages.

[edit] Creating a legacy archive

The risk register should be managed throughout the process protocol phases. Risks will either be:

Deleted/closed because they have passed.
If still current, be transferred to live operation/maintenance as a part of handover.

The text in this article is based on ‘Business Management in Construction Enterprise’ by David Eaton and Roman Kotapski. The original manual was published in 2008. It was developed within the scope of the LdV program, project number: 2009-1-PL1-LEO05-05016 entitled “Common Learning Outcomes for European Managers in Construction”.

It is reproduced here in a slightly modified form with the kind permission of the Chartered Institute of Building.

--CIOB